Fixes supabase-community/supabase-csharp#192

Problem

A common C# idiom for an optional filter crashes on Get:

await client
    .From<TTable>()
    .Select("*")
    .Where(x => requestModel.FilterPredicate == null || requestModel.FilterPredicate(x)) // Boom!
    .Get();

Three defects combine in the Where translation:

1. The crash. For ||/&&, WhereExpressionVisitor combined sub-visitor results with the null-forgiving operator. A branch it has no handler for — here the delegate invocation FilterPredicate(x) — left its sub-filter null, which was stuffed into the nested criteria list and dereferenced later by Table.PrepareFilter during GenerateUrl(), producing the exact NullReferenceException stack trace in the issue, far from the user's code.
2. Closure expressions were mistranslated. requestModel.FilterPredicate == null doesn't reference the model at all, yet it was translated as if FilterPredicate were a column, producing a bogus FilterPredicate=eq. filter.
3. Nested null checks were broken. The == null → is.null conversion lived in Table.Where and only applied at the top level; inside ||/&& (e.g. x => x.Name == null || x.Name == "foo") it emitted an invalid eq. filter.

Fix

• The visitor now tracks the lambda parameter and evaluates parameter-free branches locally, folding constants through ||/&& with C#'s short-circuit semantics. The reported idiom works: when the delegate is null, FilterPredicate == null folds to true, the right side is never touched, and Where applies no filter — exactly what the reporter expected.
• A branch that references the model but cannot be translated (a compiled delegate is opaque IL — it can never become a PostgREST query) now throws a descriptive ArgumentException pointing at the conditional-query workaround, instead of an NRE at Get.
• An always-false predicate throws too: silently matching all rows would be dangerous for Update/Delete.
• The null-check conversion moved into the visitor, so is.null/not.is.null is emitted at any nesting depth.
• PrepareFilter guards against null nested filters reachable via the public QueryFilter(Operator.And/Or, …) constructor with a clear exception.

Deliberately out of scope: the other known LINQ-provider gaps (closure-list Contains, bool member columns, column-vs-column comparisons) — same family, separate issues.

Tests (written first, red → green)

New tests in LinqTests assert on GenerateUrl() (no live instance needed):

Full suite against a fresh supabase start stack: 96/96 pass (rebased on #121).